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SECTION  1 


INTRODUCTION 


The  Discrete  Address  Beacon  System  (DABS) ,  when  deployed 
within  the  National  Airspace  System  (NAS) ,  will  provide 
surveillance  of,  and  two-way  digital  communications  with  air¬ 
craft  equipped  with  DABS  transponders,  and  provide  surveillance 
of  ATCRBS-equipped  aircraft. 


Surveillance  data  and  data  link  services  will  be  provided 
to  Air  Traffic  Control  (ATC)  facilities  (terminal  and  en  route) . 
Each  DABS  sensor  will  have  two  digital  links  to  each  ATC 
facility:  a  two-way  communications  link  and  a  one-way  surveil¬ 

lance  link  from  sensor  to  ATC.  The  surveillance  link  is  not 
addressed  in  this  document.  Surveillance  data  formats  and  the 
ATC  interface  hardware  required  for  receipt  of  these  messages 
are  described  in  References  1  and  2,  respectively. 


All  communications  messages  transmitted  and  received  by 
DABS  are  in  accordance  with  the  protocol  and  formats  of  the 
Common  ICAO  Data  Interchange  Network  (CIDIN) .  When  DABS  is 
interfaced  to  the  en  route  ATC  system,  all  communications 
messaqes  transmitted  on  the  two-way  link  between  each  DABS  sensor 
and  the  en  route  center  will  be  processed  by  the  Front  End 
Processor  (FEP)  which  will  be  located  at  the  ATC  facility.  The 
FEP  is  a  DABS  communications  processor  which  provides  transla¬ 
tion  between  the  CIDIN  protocol  and  formats  and  the  protocol 
used  by  the  En  Route  Central  Computer  Complex  (CCC) .  The  pur¬ 
pose  of  this  document  is  to  define  the  protocol  and  message 
formats  used  between  the  FEP  and  the  En  Route  CCC.  This  protocol 
is  sometimes  referred  to  as  the  FEP/9020  protocol. 


SECTION  2 
FEP  INTERFACES 


2.1  DABS /FEP  INTERFACE 

Each  DABS  sensor  interfaced  to  a  particular  en  route  ATC 
facility  shall  have  it's  two-way  communications  link  interfaced 
to  the  FEP.  Incoming  DABS-to-ATC  messages  shall  be  tagged  by 
the  recipient  interface  with  the  identity  of  the  sensor.  The 
FEP  shall  direct  ATC-to-DABS  messages  received  from  the  En  Route 
Central  Computer  Complex  (CCC)  to  the  desired  sensor  interface. 
Message  exchanges  between  the  DABS  and  FEP  shall  conform  to  the 
CIDIN  protocol.  DABS-to-ATC  and  ATC-to-DABS  messages,  as  well  as 
the  CIDIN  protocol  to  be  used,  are  specified  in  Reference  1. 


2.2  FEP/EN  ROUTE  CCC  INTERFACE 

The  interface  between  the  DABS  Front  End  Processor  (FEP) 
and  the  En  Route  CCC  is  specified  in  Reference  2. 
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SECTION  3 


FEP/EN  ROUTE  CCC  COMMUNICATIONS  FORMATS 


The  following  paragraphs  describe  the  frame  format  which  is 
used  for  all  communications  between  the  FEP  and  the  En  Route 
CCC  (also  called  the  9020  CCC) .  Also  defined  in  the  following 
paragraphs  are  the  FEP/9020  CCC  protocol  messages  and  formats. 
DABS-to-ATC  messages  received  by  the  FEP  from  DABS  are  placed 
within  the  Data  Block  of  the  frame  and  transmitted  to  the  9020 
CCC.  ATC-to-DABS  messages  are  also  placed  in  the  same  format 
by  the  9020  CCC.  FEP/9020  CCC  protocol  messages  (i.e.,  messages 
which  originate  or  terminate  in  the  FEP)  are  also  placed  into 
the  Data  Block  of  the  frame  by  the  FEP  and  the  9020  CCC. 

3.1  FRAME  FORMAT 

All  messages  to  be  transferred  between  the  FEP  and  the  9020 
CCC  shall  consist  of  one  Header  field  followed  by  one,  variable 
length.  Data  Block  as  shown  in  Figure  3-1.  The  Header  field  is 
24  bits  in  length  and  contains  information  about  the  Data  Block. 
The  Data  Block  is  an  integral  number  of  bytes  (byte  =  8  bits)  in 
length  and  contains  the  message  type  code  and  message  contents 
being  transferred  between  the  9020  CCC  and  the  FEP.  The  minimum 
length  of  the  Data  Block  is  one  byte  and  the  maximum  length  is 
250  bytes. 

3.1.1  Header  Field  Content 

Figure  3-2  shows  the  detailed  content  of  the  24  bit  Header 
field.  The  following  paragraphs  describe  the  Header  field  con¬ 
tents  : 

3. 1.1.1  Label  (bits  1  and  2) 

Label  is  a  2-bit  field  which  is  always  encoded  as  binary 

ones. 

3. 1.1. 2  Retransmit  (Rtx)  (bit  3) 

A  binary  zero  setting  of  bit  3  indicates  that  the  message 
number  in  bits  17-24  is  a  sequentially  ordered  number  denoting 
that  a  new  message  follows  in  the  Data  Block.  A  binary  one 
setting  of  bit  3  indicates  that  the  message  number  in  bits  17- 
24  is  not  sequentially  ordered  and  is  the  original  message  num¬ 
ber  of  a  message  being  retransmitted  in  the  Data  Block. 

Messages  shall  be  retransmitted  upon  request  or  whenever  a 
message  requiring  an  Accept  is  not  accepted,  rejected,  or  re¬ 
quested  for  retransmission  within  the  DABS  Retransmission  Time 


Header  Field 

Data  Block 

(24  bits) 

(integral  #  of  bytes) 

Figure  3-1 

.  Frame  Format 

Label  Rtx  FEP  Interface  Byte  Message 

_ Address _ Count  Number 


1  2  3  8  16  24 


Figure  3-2.  Header  Field  Content 


Message 

Type  Code _ 

1  8  9 


Data  Field 
(variable  length) 
x 


- Integral  number  of  bytes - 

(1  to  250) 


Figure  3-3.  Data  Block  Content 
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Parameter  (DRTP) .  DRTP  is  defined  as  3(0. 5-5.0,  .5)*  seconds. 

The  sending  processor  will  continue  to  attempt  retransmission 
every  DRTP  seconds  for  the  DABS  Transmission  Retry  Times  (DTRT) 
parameter.  DTRT  is  defined  as  1(0-10,  1)  times.  Failure  to 
deliver  after  DTRT  times  shall  be  logged  and  the  subject 
message  discarded. 

3. 1.1. 3  FEP  Interface  Address  (bits  4-8) 

Bits  4  through  8  contain  the  5-bit  address  of  the  interface 
from  which,  or  to  which,  the  message  is  being  sent.  In  the 
case  of  ATC-to-DABS  messages,  it  is  the  address  of  the  DABS  site 
to  which  the  message  is  to  be  sent.  In  the  case  of  DABS-to-ATC 
messages,  it  is  the  address  of  the  DABS  site  which  transmitted 
the  message.  In  the  case  of  FEP/9020  CCC  protocol  messages  it 
is  the  address  of  the  FEP.  The  FEP  address  is  00000. 

3. 1.1. 4  Byte  Count  (bits  9-16) 

Bits  9  through  16  contain  the  number  of  bytes  contained  in 
the  Data  Block.  These  bits  represent  a  number  from  1  to  250 
bytes.  Bit  9  is  the  most  significant  bit  and  bit  16  is  the  least 
significant  bit.  This  byte  count  does  not  include  the  three 
bytes  of  the  Header  field. 

3. 1.1. 5  Message  Number  (bits  17-24) 

Bits  17  through  24  contain  the  message  number  for  this 
message.  These  bits  represent  a  number  from  1  to  255.  Messages 
sent  across  the  FEP/9020  CCC  interface  are  numbered  to  maintain 
interface  integrity  and  to  provide  a  reference  to  messages  pre¬ 
viously  sent.  FEP  originated  messages  will  be  numbered  by  the 
FEP  and  9020  CCC  originated  messages  will  be  numbered  by  the 
9020  CCC. 

Messages  in  either  direction  shall  be  sequentially  numbered 
in  the  order  sent  unless  the  retransmit  bit  is  set  in  the  Header 
field.  When  the  retransmit  bit  is  set  the  message  number  shall 
be  the  same  as  that  previously  used  for  the  same  message. 

Messages  are  sequentially  numbered  from  1  to  255.  When  a 
message  numbered  255  is  sent,  the  next  message  will  normally 
be  numbered  1.  If  either  side  of  the  interface  receives  a  Reset 

*  NOTE :  parameters  specified  herein  utilize  the  following 
notation : 

p  =  w (x-y ,  z) 

Meaning:  The  parameter  p  sha?l  be  included  in  the  program  and 

given  the  nominal  value  w.  All  programs  using  that 
parameter  shall  accept  a  range  of  parameter  values 
from  x  to  y  in  steps  of  z. 


5 


miii  urnrmrip  fifinw 


Message  it  should  expect  the  next  message  to  have  a  message 
number  of  1.  The  Reset  Message  will  always  have  a  message  num¬ 
ber  of  zero  in  its  Header  field.  The  message  transmitted 
following  a  Reset  Message  will  have  a  message  number  of  one. 

3.1.2  Data  Block  Content 

The  format  of  the  Data  Block  is  shown  in  Figure  3-3.  It 
has  a  variable  length,  with  a  minimum  length  of  one  byte  and 
a  maximum  length  of  250  bytes. 

The  Data  Block  consists  of  a  one-byte  message  type  code 
and  a  0-249  byte  data  field.  For  DABS-to-ATC  messages,  this 
content  (type  code  and  data  field)  is  the  content  of  the  Link 
Data  Field  (see  Reference  1)  which  the  FEP  places  into  the  Data 
Block  unaltered.  Conversely,  the  contents  of  the,  unaltered. 

Data  Block  of  ATC-to-DABS  messages  received  from  the  9020  CCC 
will  be  the  Link  Data  Field  of  the  CIDIN  protocol  format  for 
transmission  to  the  DABS  site. 

The  Data  Blocks  for  the  FEP/9020  CCC  protocol  messages  are 
similar  to  those  discussed  above.  However,  the  message  type 
codes  and  Data  Field  contents  are  unique  to  this  interface. 

They  are  discussed  in  detail  in  Section  3.2. 

3.2  FEP/9020  CCC  PROTOCOL  MESSAGES 

Messages  which  originate  or  terminate  in  the  FEP  are  called 
FEP/9020  CCC  protocol  messages  (or  En  Route  CCC  protocol  messages) . 
The  following  paragraphs  define  the  FEP/9020  CCC  protocol  messages 
(message  type  and  data  field)  and  describe  the  conditions  under 
which  each  message  is  used  to  effect  the  "protocol"  between  the 
FEP  and  the  9020  CCC. 

3.2.1  FEP/9020  CCC  Protocol  Message  Formats 

Table  3-1  lists  the  Data  Block  formats  (message  type  code 
plus  data  field)  of  the  FEP/9020  CCC  protocol  messages.  Note 
that  some  of  the  messages  do  not  contain  a  data  field. 

3.2.2  FEP/9020  CCC  Protocol  Messages-Data  Field  Content  Definitions 

The  following  paragraphs  define  the  contents  of  the  FEP/ 

9020  CCC  protocol  message  data  fields. 

3. 2.2.1  FEP  Status 

The  FEP  status  field  shall  contain  information  relative  to 
the  status  of  the  FEP.  Bits  9-12  are  coded  in  hexadecimal  as 
follows : 

0  -  no  error 

1  -  voting  error 

2  -  uncorrectable  memory  error 

3  -  unable  to  receive  from  9020  CCC 
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Initialization 


lO  0  0  1  0  0  0  01 
1  8 

Interface  Initialization 


0  0  0  1  0  0  0  1 


1  8 
Initialization  Response 


00010010  |  FEP  Status  1  Sensor  Interface  Status 
1  8  9  16  17  32 

FEP  Status 


00010011  I  FEP  Status  I  Sensor  Interface  Status 


1 


Accept 


8  9 


16  17 


32 


00010100  |  Ref.  Message  No. 
1  8  9  16 

Reject 


0  0  0  1  0  1  0  1 

Error  Code  Ref.  Message  No. 

1  8 

Retransmit 

9  16  17  24 

0  0  0  1  0  1  1  0 

Ref.  Message  No.  | 

1  8 

Reset 

9  16 

0  0  0  1  0  1  1  1 

1  8 

FEP  Test 

0  0  0  1  1  0  0  0 

Test  Data 

1  8  9 

FEP  Test  Response 


A0 


0  0  0  1  1  0  0  1 


Test  Data 


1 


8  9 


40  41 


Ref.  Message  No. 


48 


Table  3-1.  FEP/9020  Protocol  Messages 
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4  -  FEP  overload 

5  -  FEP  startover 

6  -  bad  9020  CCC  test  response 

7  -  message  number  received  greater  than  DWMP 

from  last  message 

Other  codes  are  not  used. 

3. 2. 2. 2  Referent  Message  Number 

The  Referent  Message  Number  contained  in  the  Reject,  Accept 
Retransmit  and  FEP  Test  Response  messages  is  a  copy  of  the 
message  number  from  the  header  field  of  the  message  for  which 
the  response  message  is  being  generated.  If  a  Reject,  Accept, 
Retransmit  or  FEP  Test  Response  message  is  received  with  a 
Referent  Message  Number  for  a  message  not  in  storage,  it  shall 
be  ignored. 

3. 2. 2. 3  Sensor  Interface  Status 

The  Sensor  Interface  Status  field  shall  contain  information 
relative  to  the  status  of  the  interfaces  between  the  FEP  and 
attached  DABS  sensors.  Each  bit  of  this  field  shall  indicate 
the  status  of  the  interface  to  one  of  the  attached  sensors. 

The  first  bit  of  the  Sensor  Interface  Status  field  (bit  17  of 
the  protocol  message)  corresponds  to  FEP  interface  address 
00001;  the  second  bit  corresponds  to  FEP  interface  address 
00010,  etc.  The  bits  are  defined  as  follows: 

0  -  CIDIN  communications  available  (or  no  sensor  interface) 

1  -  CIDIN  communications  not  available 

3. 2. 2. 4  Error  Code 

Bits  9  through  16  of  the  Reject  message  indicate  the  reason 
for  rejection  of  a  particular  message.  It  is  encoded  in  hexa¬ 
decimal  as  follows: 

01  =  incorrect  address  in  the  Header  field 

02  =  message  rejected  by  addressed  sensor 

03  =  communications  outage  with  addressed  sensor 

3 . 2 . 2 . 5  Test  Data 

Test  Data  is  a  32-bit  field.  Contents  may  be  defined  by 
the  originator.  Each  message  may  be  different.  The  test 
data  field  received  in  a  Test  message  shall  be  duplicated  in 
the  associated  Test  Response  message. 
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3.3  FEP/9020  CCC  PROTOCOL 


The  following  paragraphs  define  the  use  of  the  FEP/9020 
CCC  protocol  messages. 

j  3.3.1  Initialization  Message  (Type  Code  0001  0000) 

I  The  Initialization  message  shall  be  sent  by  the  9020  CCC 

whenever  the  9020  CCC  is  initialized.  When  the  FEP  receives 
this  message  it  shall  initiate  a  startover,  i.e.,  clear  all 
pending  message  files,  initialize  all  hardware  and  software,  and 
’  determine  the  status  of  all  sensor  interfaces.  Following  a 

!  successful  startover,  the  FEP  shall  respond  with  an  Initializa¬ 

tion  Response  message  with  the  FEP  Status  field  set  to  code  5. 

If  the  startover  is  unsuccessful,  the  FEP  shall  respond  with  an 
I  Initialization  Response  message  with  the  error  detected  code  in 

<  the  FEP  Status  field.  The  9020  CCC  shall  repeat  the  Tnitializa- 

i  tion  message  every  5  seconds  until  an  Initialization  Response 

j  message  is  received  with  no  indicated  errors.  The  Header  field  of 

the  Initialization  message  shall  contain  a  message  number  of  zero. 

3.3.2  Interface  Initialization  Message  (Type  Code  0001  0001) 

The  Interface  Initialization  message  shall  be  sent  by  the 
9020  CCC  whenever  the  9020  CCC  has  completed  a  startover.  In 
addition,  the  9020  CCC  (in  order  to  re-establish  communications 
in  case  of  a  FEP  startover)  shall  send  the  Interface  Initializa¬ 
tion  message  whenever  it  detects  a  loss  of  communications  with 
the  FEP.  When  the  FEP  receives  this  Interface  Initialization 
message,  it  shall  immediately  respond  with  an  Initialization 
Response  message  followed  by  transmission  of  any  pending  messages 
for  the  9020  CCC.  The  Interface  Initialization  message  shall 
be  repeated  every  5  seconds  until  the  9020  CCC  receives  an 
Initialization  Response  message  with  no  indicated  errors.  The 
Header  field  of  the  Interface  Initialization  message  shall  con¬ 
tain  a  message  number  of  zero. 

3.3.3  Initialization  Response  Message  (Type  Code  0001  0010) 

l  The  FEP  shall  send  the  Initialization  Response  message 

l  upon  receipt  of  either  an  Initialization  or  Interface  Initializa- 

l  tion  message  from  the  9020  CCC.  The  message  number  in  the 

'  Header  field  shall  be  set  equal  to  one.  No  other  message  trans¬ 

actions  shall  occur  until  a  successful  initialization  has  been 
completed.  Receipt  of  any  other  message  types  shall  be  ignored. 

3.3.4  FEP  Status  Message  (Type  Code  0001  0011) 

The  FEP  Status  message  shall  be  sent  to  the  9020  CCC  to 
indicate  error  conditions  which  have  occurred  in  the  FEP  or 
changes  in  the  status  of  the  FFP/sensor  interfaces. 


3.3.5  Accept  Message  (Type  Code  0001  0100) 

The  Accept  message  is  returned  to  the  FEP  by  the  9020  CCC 
to  indicate  receipt  of  valid  DABS-to-ATC  messages  and  the  FEP 
Status  or  Reset  messages. 

The  Accept  message  is  returned  to  the  9020  CCC  by  the  FEP 
to  indicate  successful  delivery  of  a  ATC-to-DABS  message  to 
the  addressed  DABS  sensor  or  the  receipt  of  a  Reset  message. 

3.3.6  Reject  Message  (Type  Code  0001  0101) 

The  Reject  message  shall  be  returned  whenever  either  the 
9020  CCC  or  the  FEP  receives  a  messaqe  with  an  illegal  FEP 
Interface  Address  in  the  Header  field,  or  whenever  the  FEP  is 
unable  to  forward  a  message  received  from  the  9020  CCC  to  the 
addressed  DABS  sensor. 

3.3.7  Retransmit  Message  (Type  Code  0001  QUO) 

The  Retransmit  message  shall  be  used  by  either  the  9020  CCC 
or  the  FEP  to  request  that  a  bad  message  or  a  missing  message 
be  transmitted  again. 

The  Retransmit  message  will  occur  as  the  result  of  parity 
errors,  improper  message  length,  and  unrecognizable  messages. 

In  addition,  this  message  is  used  to  request  missing  messages. 

This  can  occur  when  a  message  is  received  with  a  message  number 
other  than  the  expected  message  number.  If  the  received  message 
number  (for  messages  other  than  Reset,  Initialization  or  Interface 
Initialization)  is  less  than  DWMP  (DABS  Wrong  Message  Parameter) 
greater  than  the  message  number  expected,  the  recipient  shall 
request  retransmission  of  messages  with  the  intervening 
message  numbers.  DWMP  is  defined  as  4(1-10,  1). 

Receipt  of  a  Retransmit  message  requesting  a  message  not  in 
storage  (e.g. ,  response  messages)  shall  oe  ignored.  There  is 
no  requirement  to  store  a  retransmit  message  for  possible  re¬ 
transmission  . 

3.3.8  Reset  Message  (Type  Code  0001  0111) 

The  Reset  message  will  cause  the  message  numbering  to  be 
reset  so  that  the  next  message  transmitted  from  both  the  FEP  and 
the  Q020  CCC  will  have  a  message  number  equal  to  one.  The  mess¬ 
age  number  contained  in  the  Header  field  of  the  Reset  message 
shall  always  be  equal  to  zero.  A  Reset  message  shall  be  trans¬ 
mitted  v'hen  a  received  message  number  differs  from  the  expected 
message  number  by  a  number  equal  to  or  greater  than  DWMP.  New 
messages  can  be  transmitted  following  receipt  of  an  Accept  for 
the  Reset  message  or  the  generation  of  the  Accept  to  a  received 
Reset  message.  Once  a  Reset  message  is  transmitted,  all  messages 


except  for  the  Accept  of  the  Reset  or  another  Reset  shall  be 
ignored. 

Note:  Messages  received  with  wrong  message  numbers  within 

DWMP  which  are,  in  all  other  respects,  correct  shall  be  considered 
acceptable . 

3.3.9  FEP  Test  Message  (Type  Code  0001  1000) 

The  FEP  Test  message  is  used  to  determine  the  status  of  the 
interface  between  the  FEP  and  the  9020  CCC.  The  FEP  Test 
message  can  be  forwarded  as  the  result  of  an  operator  input  to 
the  FEP  or  to  the  9020  CCC.  In  addition,  the  9020  CCC  shall 
automatically  send  a  Test  messaqe  every  TMTP  seconds  when  no 
other  transactions  have  taken  place  on  the  FEP/9020  interface. 

The  Test  Message  Time  Parameter  (TMTP)  is  defined  as  10(5-60,  5) 
seconds.  The  9020  CCC  shall  determine  FEP  failures  and  output 
such  status  information  to  maintenance  personnel. 

3.3.10  FEP  Test  Response  Message  (Type  Code  0001  1001) 

The  FEP  Test  Response  message  is  transmitted  whenever  the 
FEP  or  the  9020  CCC  receives  a  FEP  Test  message. 
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